1. Field of the Invention
This invention relates to computer processes and, more particularly, to the instrumentation of computer application code.
2. Description of the Related Art
In order to better understand the operation of software processes, it is common to employ any of a variety of monitoring, profiling, and/or analysis techniques in conjunction with the software processes to be understood. Such monitoring, profiling, and analysis techniques which, for simplicity, may collectively be referred to as “profilers”, are available from many vendors or may be custom-made for specific applications. As part of a profiling or monitoring process, application code may be “instrumented” by adding instructions (i.e., code) sometimes referred to as “probes” to an application's original code. These probes may then generate additional data concerning the operation of the application during runtime.
Traditionally, there have been two general approaches to the instrumentation of application code. One approach is static instrumentation, and the other approach is dynamic instrumentation. However, both of these approaches have disadvantages. Static instrumentation generally involves replacing an application's original executables with instrumented executables. However, such an approach can be difficult to manage. One difficulty with managing statically instrumented applications is the user needs to know which executables make up their application, and which executable are instrumented and non-instrumented. Another problem with static instrumentation is that digitally-signed code generally cannot be instrumented. If a digitally signed assembly, library, or other code is instrumented, the process which loads the instrumented code may reject it due to a failed signature verification.
In dynamic instrumentation, application code (e.g., intermediate code) may be instrumented at the time the code is actually loaded for execution. For example, in the Microsoft .NET framework, bytecodes may be instrumented when a method or assembly is loaded for just in time (JIT) compilation. Alternatively, code may be instrumented when a class is loaded in a Sun Microsystems' Java environment. While the dynamic approach may avoid the need for replacing deployed executables on disk, it may also entail significant performance implications due to the overhead involved. Further, it may also be very difficult to support and maintain code while using a dynamic instrumentation approach, because no instrumented files are generated that can be sent to support.
In addition to the above, one of the issues with profiling code concerns the generation of too much data or information regarding the operation of a particular application. As a general matter, those analyzing the operation of various applications may not necessarily be interested in every part of the application. Consequently, various efforts may be undertaken to reduce the amount of superfluous data which is generated. One such technique for reducing the generation of unneeded data involves providing “switches” for probes which allows the probes to either be enabled or disabled. By selectively enabling or disabling probes, more or less probe data may be generated. While such a technique may reduce the production of unwanted data, the instrumentation of the code itself may cause a reduction in performance of the application. For example, while a probe may be disabled, it may generally be necessary to execute instructions in order to determine whether or not the probe is to be enabled or disabled. Therefore, instrumenting the code may in and of itself result in undesirable overhead—irrespective of whether or not probes are enabled or disabled.
Another alternative for reducing the amount of data generated by probes is to simply instrument less of the application code. However, utilizing this approach, various performance characteristics may never be captured during execution and diagnosis of a corresponding problem may be rendered overly difficult.
In view of the above, an effective and efficient method and mechanism for instrumenting application code is desired.